@sunmisc we can easily forgive you for the long absence, but can't forgive the wrong formatting of the code :) our checkers won't let us merge your code until all builds are green

@sunmisc we can easily forgive you for the long absence, but can't forgive the wrong formatting of the code :) our checkers won't let us merge your code until all builds are green

Phew, 2025 in copyright is an error, which is probably weird.
The rest of the formatting rules are pretty unfamiliar to me, but I respect them anyway and I kind of like them.

@sunmisc we can easily forgive you for the long absence, but can't forgive the wrong formatting of the code :) our checkers won't let us merge your code until all builds are green

Phew, 2025 in copyright is an error, which is probably weird. The rest of the formatting rules are pretty unfamiliar to me, but I respect them anyway

The actual test fails because of the race.

@yegor256 In fact, we can assume that the AtRho object is not thread-safe and then this test can be removed. But inside this object AtomicReference is used, even with considerations that it is for the sake of elegance, there are more efficient methods for working in one thread - setPlain / getPlain

It's not quite clear what the object should end up being thread-safe/not thread-safe, you should adjust this, either to optimize or to fix a race bug

@sunmisc as a rule of thumb, if you see a bug in master branch, report a new issue, don't try to fix it in your branch